​​Data structure and integrity

On Namecoin, similar to Bitcoin, all data are stored on multiple instances, including key/value stores as table-like databases. This way, Namecoin's data structure ensures the uniqueness of each Namecoin asset, regardless of its registration lifecycle.

Blockchain-based database

The blockchain-based database (“the blockchain”) stores hex-encoded raw data of the transactions including inputs (previous outputs such as transfers), unspent outputs (UTXOs), and name operations (e.g., name_new, name_firstupdate or name_update) along with the TxIDs of the inputs. Naturally, future transactions accessing these outputs can't be written to the current block, so it's impossible to trace a transaction history forward just by making data requests from the blockchain. While it's possible to toggle backwards by reading the TxIDs of a transaction's input, toggling forward the transaction history requires a fully indexed blockchain explorer based on a server-based SQL database. The blockchain-based transaction details of name operations include data such as the name of the cryptographic asset (e.g., d/bitcoin), its associated NMC address, and the user-generated payload data values such as DNS settings or contact data.

The purpose of making this database blockchain-based is to cryptographically secure the database against future manipulation. Each data block is therefore linked to the previous one by the hash of the previous block header written to the current block. To further verify the integrity of the transaction history, TxIDs are added to a hash- or transaction-tree, a data structure called the Merkle tree. In a Merkle tree, transactions are grouped into pairs, and a hash is calculated for each pair. In the next instance of the tree, these hashes are paired and hashed again until there remains a single root hash, known as the Merkle Root. Every node operated by a community member, not just the mining nodes, validates the integrity of this data structures.

Key/value stores

For efficient user requests, such as domain name lookups and their history, name-related data is stored additionally in a key/value store in the .\chainstate subfolder of the data directory, along with UTXO data and other blockchain state information. This database is formatted as a LevelDB database, an open source key/value store developed by Google LLC in 2004, split up into multiple files. The database contains tables such as the “name database”, which stores the decoded transaction details from the blockchain mentioned before, including the TxID of the most recent name operation and its associated NMC address, as well as the asset's name and its current user-generated data value. Another dedicated index in the LevelDB database provides the block height of the asset's expiration. If the -namehistory start parameter of the Namecoin Core wallet is set, a separate “name history” table is created to store the data that will be output on the name_history RPC call.

The start parameter can be set when starting the Core wallet via CMD console/Terminal or, line by line without the leading dash, as a parameter in the namecoin.conf configuration file in the data directory. On a fresh installation, this file needs to be created manually using a text editor. If the additional start parameter -txindex is set, another dedicated LevelDB database containing the entire transaction history will be created in the .\indexes\txindex subfolder of the data directory. Nodes running with both -namehistory -txindex start parameters are called fullnodes.

As of February 2024, the data directory of a full node is about 7.5 GB in size, of which about 1.4 GB (or about 18%) are allocated to the separated LevelDB-based key/value stores in the chainstate and txindex subfolders. While the blockchain is being distributed step by step with each block submitted over the network, the separated databases are created locally by the node from the decoded blockchain data.

Uniqueness of Namecoin Assets

As shown, a Namecoin asset is unique not only in Namecoin's blockchain-based database, but also in several other table-based indexes. Namecoin, as the very first code fork of Bitcoin back in April 2011, was designed as a blockchain DNS (Domain Name System). The uniqueness of a blockchain domain is of course a fundamental requirement for a functioning DNS. To prevent the blockchain from becoming unusable after a short period of time due to abandoned blockchain records, the consensus rules also define that the access token, consisting of the assigned NMC address and its private key, expires after a lifecycle of 36,000 blocks (about 8 month) and can't be used any longer to update the name. The owner of the private key loses ownership of the cryptographic asset if he doesn't renew in time. However, the asset itself persists regardless of its expired flag, and its data can still be accessed and even be used for DNS resolution (see section Accessing Expired Domains). Upon re-registration, same as with a regular name update within an existing lifecycle, a new access token is generated, granting ownership of the asset again.

The question of whether or not Namecoin assets can be considered NFTs comes up from time to time in public chats (see section Non Fungible Tokens). A known misconception is that re-registered Namecoin assets would just be copies of the historical ones due to the lack of cryptographic links on the blockchain between the separate transaction histories of each lifecycle. This kind of obviously biased and intentionally misleading argumentation would require that the asset doesn't exist anymore and would be recreated upon re-registration. Of course, this argument fatally fails on the simple question of how the expired flag could be set on a “non-existent” asset. Moreover, it raises the more perplexing question of how the history of an “non-existent” ​asset could be retrieved with the name_history RPC call. Also it should be noted that it's possible to re-register an expiring asset right after the last block of a lifecycle, so the name_history RPC call will show 0 blocks to go for the expired record and 36,000 blocks for the active record. In this case, the expired flag isn't even set a single moment between the lifecycles.